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SYSTEM AMP METHOD FOR COMTROLLING A DgSIGW PROCESS 

The present invention relates to a system for 
controlling a design process which finds particular 
application in the packaging industry. 

Field of the Invention 

In many industries the design process consists of 
a number of sub-design processes which relate to the 
overall design of a product or process. These Individual 
design sub-processes must be combined to produce an 
integrated outcome. For example, in the packaging 
industry in order to deliver a product to the consumers 
15 there needs to be a single consistent outcome including 

the flexible wrap which surrounds the product, the carton 
in which the flexibly wrapped products are contained for 
presentation at retail stores and the corrugated box in 
which the individual cartons are shipped to the retailer. 
Hdwever, the individual elements of this outcome are the 
result of a number of individual design sub -processes 
which need to be combined and consistent. 

Previous approaches to integrating design sub- 
25 processes have generally been linear. That is, an ad hoc 
decision has been reached deciding which design sub- 
process to begin with and the order in which the design 
sub-processes will be carried out. As a result, there is 
limited intelligent and timely interaction between related 
design sub-processes as well as little to ensure that the 
outcomes of individual design sub-processes are consistent 
with the goals of the design process and satisfy some 
local and/or global optimum requirement. Accordingly, the 
outcome of the design process is often far from optimum 
and the design process itself can follow a convoluted path 
requiring many iterations and accordingly the design 
process typically takes much longer and requires much more 
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e££ort than Is desirable. 



Further, existing systems xaake It difficult for 
different entities to engage within an integrated design 
space • 

In our PCT application, PCT/AUOl/00056, we 
proposed a system which is designed to allow the 
integration of a number of related software design 
processes to ensure that the solutions of a first design 
sub-process module do not conflict with solutions of a 
second design sub-process. 

We now propose a system for controlling a design 
process which is ed^le to control the manner in which the 
design process is carried out. 

Summary of the Invention 

There is provided a system for controlling a 
design process having a first design sub-process and a 
second design sub-process, outcomes of one of the first 
and second design sub-processes being capable of affecting 
outcomes of the other of the first and second design sub- 
processes and vice versa because of a relationship between 
one or more variables (A) of a first design sub-process 
and one or more variables (B) of a second design sub- 
process, the system having a user configurable interface 
between said first and second design sub-processes, said 
user configurable Interface allowing a user of a system to 
control said design process by specifying which of said 
one or more variables (A,B) of said first and second 
design processes are treated as "active'' variables and 
which of said one or more variables (A,B) are treated as 
^^passive*^ variables, wherein the domain of an ^active" 
variable can be modified by an internal process within the 
sub-process to which the "active'' variable belongs whereas 
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the domain o£ a passive variable is predominantly 
determined by the domains of the other variable or 
variables in said relationship, whereby specifying which 
of the variables are treated as passive and which are 
treated as active determines the manner in which said 
relationship is evaluated and the dominance of a sub- 
process in the overall design process. 

The internal process may include a user 
modification of the domain of the active variable. 

The domain of a passive variable may be 
determined directly or indirectly by way of the 
relationship specified between variables by a rule or an 
algorithm. 

The user configurable interface may define a 
plurality of relationships between the first and second 
design processes and said user configurable interface 
allow a user to select a relationship from the plurality 
of relationships. 

The user configurable interface xaay allow a user 
to select a plurality of relationships. 

Selection of the relationship may lead to 
specification of which variables are treated as active and 
which are treated as passive. 

Alternatively or in combination with the above 
approach, said user may specify a goal or goals of said 
design process in order to configure said interface. In 
which case, said user configurable interface specifies 
said relationship on the basis of the user specified 
goals. 

There may be more than one relationship between 
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the £lrst and second design sub-processes. For example, 
between different variables or different sets of 
variables. Alternatively, one of two or more 
relatlonsbips may be chosen in accordance with a preset or 
user specified rule. For exaxnple, a relationship may need 
to be changed if the value of a varisible increases beyond 
a preset value. A relationship may consist of one or more 
rules, one or more algorithms or a combination of rules or 
algorithms . 

Further, there may be more than two sub-processes 
and accordingly there may be relationships between all or 
some of the sub-processes as well as relationships between 
more than two relationships - e.g. either one to many 
relationships or many to many relationships. 

Still further, the system may allow constraints 
to be placed on a domain of a variable. The constraints 
may be ^^hard'' constraints which cannot be breached - e.g. 
to exclude unworkable values of the variable - or ^soff 
constraints which can be breached in certain circtimstances 
- e.g. if a pre-existing solution of the design process is 
just outside the constrained domain. 

Xn this respect, in some embodiments, the system 
has the ability to compare potential solutions to the 
design process with pre-existing solutions to enable pre- 
existing solutions to be brought to the attention of a 
user. 

The system typically has an optimisation engine 
for optdLmislng the design process. Typically, the 
optimisation engine will use one or more rules to analyse 
the available solutions. These rules may embody industsry 
experiences or be developed by the system based on the 
outcomes of previous design processes - i.e. the system 
may have the capability to learn. 
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Similar optimisation engines may run within 
individual design processes. 

Brief Description of the Drawings 

Figure 1 shows an interface between first and 
second design sub -processes* 

Figure 2 shows an interface between three sub- 
processes . 

Description of the Preferred Embodiment 

A design process has the end goal of providing a 
unified outcome of the design process which can then be 
put into practice. Complex design processes are typically 
the coxhbinatlon of a plurality of design sub-processes 
managed by different entitles. Here, the term '^entity'' is 
used to designate a person, group of people or 
organisation or a software module which has responsibility 
for a design sub-process. That is^ the entities are not 
necessarily different legal entities although they may be 
- for example/ when two entities conpete to provide the 
outcome of a particular sub-process. 

It will be appreciated that for a given problem 
specification each sub-process is capable of producing a 
wide variety of outcomes but these outcomes must be 
Integrated. Accordingly, it will also be appreciated that 
in controlling the overall design process there are a 
number of challenges. These include ensuring that the 
outcome satisfies the constraints of individual sub-design 
processes / allowing flexibility in the design process and, 
as far as possible, ensuring that the outcome is near 
optimal. 
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We have recognised that this requires the ability 
to exercise control over the influence that individual 
design processes and design variables have on the overall 
outcome o£ the design process. 

Accordingly, embodiments of the present invention 
provide a system for controlling a design process which 
includes a user configurable interface between design sub- 
processes which allows a user to control the influence 
individual design sub-processes have on the outcome of the 
overall design process. The embodiments of the system 
also allow the design processes to be more flexible than 
existing design processes and to control collaboration of 
different design processes. 

The user configurable interface is designed to be 
used by a user who has control of the overall design 
process. Herein this user is designated as the ^project 
manager'' in order to distinguish the project manager from 
other users of the system - e.g. users of individual sub- 
processes « 

Xn the preferred embodiment, the user 
configurable interface is a web (internet or intranet) or 
client server based application which allows the project 
manager to control the design process as well as for the 
individual sub-processes. 

The project manager specifies which design sxab- 
process and which variables of individual design sub- 
processes will form part of the overall design process as 
well as defining the manner in which they will influence 
the overall design process* Further, the user 
configurable interface allows the user to specify the 
relationships between individual variables which are used 
in the rules which are used in order to evaluate which 
outcome or outcomes should be adopted for the design sub- 
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process. Herein the term ^variable" is used in a broad 
sense to refer to the aspects o£ a design siib -process 
which may be varied* In some cases a sub-process will 
also have ^^parameters'' which are generally \xnchanging 
variables and which need to be made available to another 
process - e.g. because of a relationship with that 
process . 

The relationships between the sub-processes will 
determine the extent to which sub-processes are dependent 
on each other - i.e. the extent of coupling of individual 
design sub-processes to other STib -processes. 

The user configurable interface will now be 
described in relation to a design process which involves 
first and second siib -processes for sixnplicity of 
description. Persons skilled in the art will appreciate 
that the invention can be extended to any nuniber of sub- 
processes. 

In the web-based application interface a use of a 
design sub-process is informed of required tasks by an e- 
mail message or other appropriate messaging system, 
typically by a workflow process, and with a hyperlink to 
the system. The user only has access to appropriate pages 
associated with a set of tasks they are required to 
perform and if required their task brief. The pages 
include a set of choice or input variables, which are 
implicitly constrained. The current constraints (range 
and or discrete) for variables are given where appropriate 
and editable if active and not if passive (e.g. visible 
but greyed out) . Alternative techniques could include a 
portal or sm auction process where the participants would 
be supplied with a specification (containing similar 
variables and constraints) to satisfy and provide 
solutions the and associated quotes through the portal 
which would then be incorporated into the integrated 
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process • 

Setting up the Design Process 

5 In the preferred embodiment, a configuration 

module Is used to configure the Interface. The 

configuration mo^dule allows a project manager to specify 

the goals of the design process. The system then uses 

ezKibedded logic to determine from the goals which siib- 

10 processes and which variables will form part of the 

« 

Interface between sub -processes as well as which rules and 
algorithms are used to specify the relationships between 
the variables of the first design sub-process and the 
variables of the second design sub-process. In this way# 

15 the user configurable Interface is able to exnbody user 
experience. However, the system also allows a user to 
individual tailor the Interface. That is, the project 
manager may either specify the interface from scratch or 
may modify the interface which is provided by the system 

20 in response to the project manager defining their goals. 

Varl€J3le, Algorithms and Rules 

The three main components which allow the system 
25 to be implemented is the manner in which the variables, 
algorithms, rules and goals are handled « 

Variables can be assigned different 
characteristics which determine the manner in which 
30 relationships between variables are evaluated and the 

dominance of a sub-process in the overall design process. 
Variables can be assigned either an ^^actlve'' or ^^passlve'' 
nature • 

35 The domain (l,e. the set of possible values) of a 

^^passive'' variable will be determined by other variables, 
and rules and algorithms. That is, a passive variable 
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becoznes a dependant variable in a relationship with other 
varl£d:>les. The relationship .is typically specified by one 
or more algoritfaxns and/ or one or znore rules* Accordingly, 
the sub-process to which the variable belongs will respond 
to changes laade to the variable through its relationship 
with other variables but will not be able to modify its 
values. However, the sub-process will be able to 
constrain the domain of the variable so that it does not 
take unworkcQ>le values. 

In contrast, an ^^active'' variable can be modified 
by the sub-process with which it is related again, within 
constraints set for that variable by the sub-process. 
Therefore, changes to an active variable by a sub-process 
will propagate to variables with which the active variable 
is related by way of the relationship specified by an 
algorithm and or rule. 

A variable may also have **hard" or "soft" 
constraints • 

Typically, a "hard" constraint will be applied by 
the sub-process. A hard constraint in effect indicates 
that the s\ib-process is Incapable of providing solutions 
which lead to that variaa>le taking a value outside a 
particular range so that if a relationship with another 
variable calls for the variable to change, there is a 
mechanism for preventing it from taking an unaccepteO^le 
value. A soft constraint, on the other hand, could be 
applied by either the sub-process or the user interface. 
Therefore, the project manager may apply a soft constraint 
to indicate the constraint is not significant in the 
overall scheme of things. For example, a project manager 
may place a soft constraint on the area or volume 
efficiency of a packing arrangement or material 
perforzaance to cost ratio. The latter are typical 
examples of constraints where there is not a strong degree 
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of certainty in their choice and hence there may not be a 
good reason to adhere to the constraint. In addition in 
some cases they may not have much of an overall affect on 
an optimisation objective function (e.g. cost), and hence 
should not be a strong determinant of the solution space 
(i.e. the possible outcomes), whereas a hard constraint 
generally has a strong physical limit. During 
optimisation, if the current solutions do not meet a 
specified criteria, the optimisation engine may modify the 
domain of the softly constrained variable to search for 
better solutions. The soft constraints can prevent 
excellent solutions being dismissed for spurious reasons - 
for exaxnple because an inappropriate and unrealistic or 
uncertain choice of efficiency level which may not in fact 
have a great deal of influence on the cost effectiveness 
of the solution. The system can be configured so that the 
type of constraint defaults to soft for some types of 
variables . 

From the perspective of a s\ib-process the soft 
constraint may indicate that the sub-process prefers to 
provide solutions within a specific rsuige but will move 
outside of that range if necessary. 

The rules are eznbodied by one or more sets of 
rules engines. The rules engines manage changes and 
variables against the goals of the design process. The 
rules engines are a type of software agents and, have the 
ability to incorporate and evaluate rules, rule goals, 
goal decomposition and assertions and initiate choices and 
actions based on in-based logic. 

Algorithms take a niimber of different forms - 
Algorithms may specify a relationship between variables 
for use in solution generation. Algorithms may also 
manage the effect of changes to ensure that the 
constraints of variables are not breached and to ensure 
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that solutions proposed by one sub-process are allowable 
by another process. That is, the algorithm propagates 
constraints and manages variable domains. 

Algorithms may also conduct the procedure of 
searching for solutions, analysing performance of 
solutions, cost estimation, size determination and 
manufacturing load. 

ExainplQ 1 

In order to facilitate understanding of the 
invention, an example of an embodiment involving two sub- 
processes will be described where the first sub-process 
(SPl) is a carton and the second siob-process {SP2) is a 
corrugated box. Figure 1 provides a schematic 
representation of the components in the system, eg 
variables, algorithms and rules. Figure 1 shows the 
coxmection between variables, algorithms, and rules and 
the passive and active interface variables. In this 
example all algorithms and rules may modify or examine an 
interface variable. Accordingly, in Figures 1 and 2, all 
lines are shown passing through a central hub 70 to 
indicate that all rules/algorithsis may communicate with 
all variables. The directed lines (i.e. lines with arrows 
e.g. line 40) show where a s\2b-process algorithm or rule 
may change an active variable. As shown within sub- 
process 2 where a passive variable cannot be changed by 
the algorithms and rules of the sub-process, non-directed 
lines (i.e. lines without arrows, e.g. line 41) show 
communication/ interaction between components. There will 
also be cases where a rules component does not interact 
with the interface variables directly but does so via an 
algorithm. 

The project manager may choose one of the 
following performance goals or sub-goals: 
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1* The strengths o£ the carton and box to be 

determined Independently 

2. A proportion of the strength o£ the carton to be 

used to reduce the strength requirement of the box 

3* A proportion of the strength of the box to be 

used to reduce the strength requirement of the carton 

4. A combination of goals 2 and 3 which minimises 

the integrated carton/box cost. 

The project manager selects goal 2, the 
configuration module configures the interface so that the 
interface algorithm IA-1 determines a proportion of the 
carton strength to be used to reduce the required strength 
of the box during the design process. This goal is 
appropriate, for exaxqple, in a situation where the carton 
has already been designed or where the primary savings are 
being sought from the box. 

The project manager selects as part of the 
project configuration (specifically or by a previously 
configured and named configuration) a series of goals to 
be satisfied including goal 2 above. The system activates 
the appropriate algorithms and rules and sets variables as 
having passive/active constraints and with an associated 
soft/hard nature. In this embodiment, the system is able 
to activate algorithms within the sub-process. In other 
embodiments, particularly where a sub-process is run by a 
different business, the system may deliver a specification 
to the sub-process advising it of the required variables 
and, for example, the strength/performance algorithm which 
must be used by the sub-process. 

Xn this example, the system itself activates: 
• within SPl 

• An algorithm and a rule for strength/performance Al-1 
& Rl-1, and an algorithm gmd a rule for constraint 
management Al-2, Rl-2. 
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• within SP2 

• An algorithm and a rule for strength/performance 

& R2-1, and an algorithm and a rule for constraint 
management A2-2 & R2-2. 

• within the interface 

• An algorithm and a rule for strength/performance 
interaction IA-1 & IR-1, and an algorithm^ IA-2 and 
rule IR-1 for constraints management. 

• Globally 

• A global Constraints Manager & Global Rules Engine 
maintaining overall control of constraints 
management, utilising the algorithms and rules and 
goals such as detailed above e.g. by resolving 
conflicts between algorithms. 

These choices set variables as ^^active" and 
"passive" which are in principle straightforward - in 
setting up a project select the set of goals which 
implicitly contained such choices within a set of goals. 
Alternatively, the project manager may choose to engage 
this directly. The user for each sub process variables 
will be presented with options and a guide to choices 
(e.g* a wizard) . 

Here the sets of internal variables represented 
within VI within SPl are size, board structures, 
environment, art components and art texcqplate. Al-1 Is the 
"^selected" set strength/performance algorithm for SPl eoxd 
Rl-1 the associated rules. For estimates of carton 
coznpression loading and/or panel bulge, each performance 
relationship in Al-1 is associated with one or more 
styles. An output set from algorithm Al-1 is the maximum 
allowable load and associated stiffness (i.e. load 
deflection response) • This will typically occur during 
solution generation, locally and or globally. Before 
solution generation begins, eg during user Interaction, 
the interface determines whether there are vieUble 
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solutions of the design process by determining whether 
constraints of one siib-process prevent the other sub- 
process from producing valid solutions. During the 
variable domain definition phase Al-2 processes/manages 
constraints and variable domains, including constraint 
propagation and Rl-2 the associated rules. Subsequently, 
the set of internal variables associated with SPl are 
dynamically set/modified by a user or users associated 
with SPl, which are monitored and processed by Al-2. 
Amongst other functions, Al-2 sets or validates the 
domains of variables internally and if possible on the SPl 
interface. In addition IA-2 propagates this change to SP2 
for processing and validation via the constraint mazxager 
in SP2 namely A2-2. Similar comments apply to changes to 
variables within SP2. 

Constraint propagation is handled by an 
appropriate constraint programming technique. Constraint 
Programming (CP) is a paradigm for constructing and 
solving classes of problem in which the domains of the 
variables involved are constrained and are tmderstood in 
the context of a constraint domain. The problem solution 
consists of detesamining combinations of variable values 
that are consistent within the domain/constraints. This 
is termed constraint satisfaction. A Constraint Solver 
software coaq>onent determines if the problem is 
satisfiable, for every constraint. Given a particular 
constraint domain (Real, FD Finite Dcnoains, Integer, 
Rational, Boolean, Tree), associated Constraint Solver and 
Constraint Simplifier defines a language for developing 
programs and a means of goal(s) evaluation. A constraint 
domain details the primitive constraints, e.g. Y<aX , and 
a constraint is a conjunction of primitive constraints, 
e.g. Y ^aX /s.Yt.bZ->rcX . The Solver and Simplifier are used 
in the evaluation of goals. Such a system typically 
includes backtracking, bounds consistency for prtining 
domains, propagation rules and branch and bound solvers 
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for optimisation problesis* 



An example of propagation rules used In the 
pruning of domains, e*g. for X = YxZ (for values greater 
than zero) are: 



Some typical relationships and interactions 
associated with domain and constraint meuriagement are as 
follows. The domains of the variables VI are checked for 
consistency agadLnst the design logic and constraint 
satisfaction. This is carried out by the rules engine Rl- 
2 and constraint manager Al-2, the domains are modified 
accordingly and the user who has made the change informed 
in the event that (and why) the constraints cannot be 
satisfied « For example if a material cannot be used in a 
specific environment or with any of the styles listed in 
the style domain then this material is deleted from the 
material domain associated with VI and the SPl interface* 
This decision and its dependencies may be stored for 
future consideration if and when the basis for the 
decision is no longer valid. 

The rules engine is implemented using constraint 
logic programming. Constraint logic programming (CLP) 
combines the constraint programming paradigm with a logic 
programming paradigm. Logic programming (LP) deals with 
symbolic logic computation and is primarily declarative in 
nature (what) rather than procedural (how) . The former is 
the focus of the programmer/problem modeller and the 
latter is essentially facilitated by the system. The 
modelling paradigm is concerned with facts, rules, goals, 
queries, predicate logic (first order) etc. The CLP 
paradigm defines a family of languages. Prolog is £ux 
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example wherein a LP prograaomlng language is extended t:o 
encapsulate CP, by introducing other types o£ constraints 
in addition to matching, to give an essentially CLP 
paradigm. CLP's are made up of rules, which can be 
recursive* These let the programmer define predicates 
which are simply user defined constraints or relations. 
Multiple rules allow a predicate to have more than one 
possible definition. 

CLP essentially separates the problem solving 
process from the constraint management* Rules engines can 
direct the problem solving process by making choices of 
values to be assigned to variables but can also reject 
these assignments, (e.g. in response to a constraint 
violation) . The constraint management process may reduce 
variable domain choices, possibly at the direction of a 
rules engine, via constraint propagation. The constraint 
management process, using constraint propagation, may 
return the consistent or inconsistent choices to the rules 
engine for decision making as well as performing automatic 
consistency checking as varied^le value assignments are 
made by selection/decisions etc. Constraints may be 
activated or de-^activated by a rules engine or a 
constraints manager. The rules engine may also request 
the constraints manager to supply a reason for a resultant 
inconsistency . 

For each style there will be a number of art 
templates appropriate for the type of art objects chosen. 
For each style (in combination with each material) and set 
of specific art objects, (si2se, aspect ratio, positioning, 
art template rules etc) , minimum values for, or 
conibination of, each carton dimension can be determined 
and used as a constraint. The size domain at the 
interface is the union of domains associated with each 
style/material/art object set combination. The latter may 
be modified by size constraints, which are, for example. 
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supplied by user, or from manufacturing processes etc. in 
this way the interface size domain of SPl is presented to, 
and for use by, the rules engine IR-2 and the interface 
constraint manager algorithm IA-2 for propagation to SP2. 

The algorithms, Al-1 and A2-1 are respectively 
concerned with determination of a set of carton and box 
strength performance measures (e.g. top load, stiffness & 
bulge) . lA-1 is concerned with the strength interaction 
of the carton and box and monitors and utilises the state 
of the performance measures active variable set on the 
respective interfaces. Al-1 interacts with VI to monitor, 
read or modify the state of the set of variables VI. This 
may be via an on change event associated with the variable 
or via a listening process say if there is a highly 
distributive nature. A change in VI (e.g. by a user), may 
trigger activity within Al-1 which may be subsequently 
propagated into the interface and hence to other sub- 
process interface variables etc. Al-1 monitors change in 
a set of variables in VI via a ^listening'' or polling 
process. 

As a result of the selection of the goal, the 
following interface variables for SPl are sets materials, 
styles, arrangement/orientation into the box, mass, 
perfoxmance variables set and. size/dimensions, and they 
are all set to be ^^active". This is selected by the user, 
generally in the setting up of a goal but may be directly 
imposed. Each relationship between variables will dictate 
the extent of the set of choices the user can make, i.e. 
at least one must be active otherwise the relationship 
expresses a fact. The interface variables for SP2 are 
material, style and size/dimensions and performance 
variables set. Material and style are active variables 
and the size/dimensions are passive variables. As a 
result of a variable being given the property of ^^passive" 
or "active'', via selection of a set of goals, the ability 
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of a user, or algorithms, o£ a sub-process to influence 
the domain of a variable are either enabled or disabled. 
Xn this way the user is able to configure the relative 
dominance of a design sub-process through the selection of 
5 design goals. That is, the algorithms and rules selected 
in association with the goals dictate the way they 
interact with the internal and interface variables. 

A ^^passive" or **active" property of an interface 
10 variable relates to the ability of the sub-process 
algorithms and rules to change their domain. The 
interface algorithms and rules may be able to modify a 
domain if this is required to pursue and satisfy a goal, 
irrespective of whether the variable is ^active" or 
15 ^^assive", from a sub-process perspective. 

After the framework for the design process has 
been specified and checked for consistency, the design 
process begins. This can be initiated by a user when the 

20 user knows they are in receipt of sufficient information 
or the system can send a message to the user of a sub- 
process asking them to engage a design task. A user 
associated with SPl makes a change to the carton size 
within VI. Given that there are 

25 relationships/rules/constraints involving styles and size 
and styles and materials this change activates Al-2, which 
then reassesses the style, board structure, and size 
domains relative to the SPl user's current choice. The 
choice of art cosponents/art templates will constrain size 

30 domains and this impact will be via its effect on the size 
domain. This results in Al-2 modifying the style, 
material and size domains on its interface. This 
interface change then activates constraint 
manager/algorithm IA-2 (IA-2 monitors change in a set of 

35 SPl interface variables via a ^^listening*' or polling 

process) which evaluates and propagates the change to SP2, 
resulting in the size domain of SP2 being modified. 
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The change bo the carton size also triggers the 
rules engine 1R*1 to reassess the strength interaction 
algorithm XA-1 (the varied>le cheuige results In IA-1 
sending 1R*1 a message to re-evaluate the selected set o£ 
rules/logic and goals) . This can be handled either by lA- 
1 monitoring variable changes and then passing them to IR- 
1 or by IR-1 monitoring them directly depending on the 
con^lexlty o£ the evaluation. This is a system design 
decision on how rules are best handled. IR-1 evaluates 
the state/values on Interfaces from SPl & SP2 and relays 
back to XA-1 appropriate measures to be taken by or 
modifications of ZA-1 in performance evaluations during 
the solution generation phase. For exan^le the change 
activates ZR-1. XR-1 evaluates the size domains on SPl & 
SP2 and the orientation & arrangement from SPl (this 
includes loading allowance and headspace) • The result is 
that XR-1 activates a ^^bulge performance measure'* to be 
included within XA-1 - given a specific orientation and 
level of loading allowance • From this analysis the 
addition of bulge results IA-1 modifying the size domain 
on the SP2 interface. R2-1 responds to this change and 
R2-1 takes the new size domain and modifies the style and 
material domains of SP2« 

Each change must be sanctioned. Xf the variable 
change associated with SPl is in conflict with variable 
domains of SP2 then the latter may be modified (typically 
expanded) by the interface components, XA-1 or XR-1, 
within the absolute constraints set by SP2 . Xf the 
changes cannot be satisfied by modification other than 
violating latter the user is informed or blocked from 
making the change. 

Assimilng the variable domains are in a 
satisfactory state (i.e. the domain is not empty/null, the 
constraints are satisfied and solutions can be generated) 
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the user may initiate an integrated solution generation 
process over the two design sub-processes (note that, when 
the design process allows, solution generation or 
optimisation algorithms local to a sub-process may also be 
5 initiated) • The constraint manager search algorithm Al-2, 
I A- 2 and A2-2 process and select solution options from the 
appropriate variable domains. The ntixnber o£ combinations 
to be tested can be reduced by techniques such as a bounds 
consistency checking and branch and bound. This process 

10 involves determining a carton performance Interaction and 
box performance evaluation. Algorithms lA-1 & A2-1 are 
used to evaluate the box materials on the basis that the 
strength requirement can be reduced using the calculated 
strength contribution and stiffness from the cartons 

15 contained by a box« The carton and box specifications, 

associated with a solution are checked by the appropriate 
rules engines to ensure suitability of manufacture and . 
compatibility with filling lines. Given that an 
integrated outcome is consistent with the variable 

20 domains/constraints and rules it is saved to memory and 

subseq[uently presented to the project manager as part of a 
solution set associated with the current state of the 
design definition. 

25 Where solutions do not present themselves, the 

constraint manager may perform checks against soft 
constraints. Constraint manager typically embodies ^^fuzzy 
logic" to enable it to determine wherein self constraint 
should be breached. 

30 

The project manager can then select a solution or 
alternatively ask for further analysis to be performed 
(e.g. on cost or setting another goal to differentiate 
solutions) before selecting a solution. 
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Exaxrole 2 

Referring now to Figure 2 there is shovna a 
5 schematic representation o£ an interface between three 
sub-processes. The second example is for illustrative 
purposes of potential ftinctions cuid does not relate to 
specific sub-processes. Box 50 indicates the user 
interface configuration module which is used by the 
10 project manager to configure the design process as 

indicated by arrows 54. In this embodiment the project 
manager is capable of configuring first design sub-process 
SPl, second design sub-process SP2 and third design sub- 
process SP3 as well as configuring interface 55. 

15 

In Figure 2, dotted circles represent active 
interface variables, circles with thick borders represent 
passive interface variables and circles with thin borders 
represent internal variables. The letter A is used to 

20 designate algorithms, the letter R is used to designate 

rules and the letter V a set of variables. The numeral to 
the left of the hyphen indicates to which sub -process the 
algorithm or rule belongs, and the numeral to the right of 
the hyphen indicates the nxmiber of the algorithm or rule 

25 within the module. The letter I indicates that the 
algorithm or rule belongs to the interface. 

As shown by design sub-process 1, a design sub- 
process may incorporate a number of different algorithms 

30 which interact with the variable set tmder the control or 
management of a rules engine Rl-1. The set of variables 
56 are all active and hence tend to drive the overall 
design process. However, the algorithms Al-1 and Al-2 
also interact with other passive variables related by 

35 filling line 57 and manufacturing side 58 which csuinot be 
altered by Al-1 or Al-2. 
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Design std3-process SP3 shows that complex 
processes may be at work within in a design sub -process 
with a niunber o£ different algorithms and rules 
competing/ combining to produce the result. Further, as 
5 indicated by active variable 58, the system can 

incorporate other active variables which are not part of 
the design process as far as the interface is concerned* 
Active interface variable 58 may indicate a separate 
interface with service provider 59 who r\ins manufacturing 
10 site 60. 

The group of algorithms and rules IA-1, IR-1 and 
IA-2 indicate that for example rules engine 1 may monitor 
IA-1 and substitute XA-2 for IA-1 if certain predetermined 

15 conditions are met. IA-3 indicates that interface 

algorithms do not need to interact directly with interface 
variables. lA-3 can perform some intermediate task such 
as calculating a value £roBx the passive variable with 
which it is associated and then passing this value to 

20 lA-1. 



Various modifications will be apparent to persons 
skilled in the art and should be considered as falling 
within the scope of the present invention. 
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